Generate binary files in bin\Debug, bin\Release respectively.

…so that the program works on Target Platform=AnyCPU.

The DllImport that caused problem was WindowFromPoint(). It accepts one POINT parameter as opposed to two int parameter. With two int parameters, it happens to work ONLY on Target Platform=x86, but not AnyCPU or x64.

… ChildWindowFromPoint was wrong.

Fix repetitive and erroneous code in picTarget_MouseUp().

Roughly tested on Win10.1909 and Win7, both OK.

* WindowFinder add new property isFindOnlyTopLevel, setting it to true to find/target only top-level window.
* Even if isFindOnlyTopLevel=false, human user can press Ctrl(while aiming) to target only top-level window. // Implementation is a bit ugly yet, using a 100ms timer to check for Ctrl key.

Pending Q: picTarget_KeyDown() cannot be triggered, why?

…this works for DWM-enabled top-level window.

-- user determines which to use via property WindowFinder.tgwHighlightMethod .

(roughly tested)

…D, not blindly placed at TOP-MOST.

dpiAware.manifest is provided as a spare. If you tell csproj to embed it, it will become Sys-dpi aware on Win7 and Per-monitor-dpi aware on Win81+.

dpiAware-SysDpi.manifest
-- use at your request.

… grabber highlight a StdDpi target window with wrong FrameRgn size.

    internal static class Win32
->

    public static class Win32

… work correctly when Win7 System-DPI is set to non-100%. The program could not distinguish whether a target window is a DPI-unaware one or an Sys-dpi-aware one.

Now, with the help of DwmGetWindowAttribute(DWMWA_EXTENDED_FRAME_BOUNDS), we can distinguish them finally.

Key function: Win7_SpecialAdjust().

…ebug-Output window.

Remove code:
  this.CancelButton = this.btnClose;

…onstrating and debugging.

…ned by ClientToScreen).

This reveals a subtle problem: When we set primary screen DPI to non-100%, we will see different behavior on Win7 vs Win10 when we drag the finder *across* a DPI-unaware window and a DPI-aware window. Win7 will exhibit some buggy(or say, inconsistent) behavior, while Win10 behaves consistently.

…y when the target-window is REALLY changed(avoid verbose repetitive calls).

I think we should use a new name that is a bit more unique.

If monitor is 150% DPI and wcFinder is SysDpi-aware, the target-window physical pixel width WAS reported too large.

… report pixel width as if all monitors are of same DPI-scaling value, that is, I may give wrong result in case of Win81 using mixmode-scaling.

So TestApp title says ver:2.1.10 .

Update Win81 warning text.

On Win81, when "Let me choose one scaling level for all my displays" is NOT ticked, changing DPI scaling does NOT require user logout and login. This means, DESKTOPHORZRES and HORZRES value can change dynamically. So on Win81, the caller should pass in need_fresh=true to get fresh value.

Rename: Win7_SystemDpi() -> Win_GetPrimaryScreenDpi().